Break-out Box
Volume Number: 7
Issue Number: 12
Column Tag: C Workshop
Go With the Flow
By Byron Miller, Minneapolis, MN
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
An Alternative to Expensive Protocol Analyzers
I had a problem that needed a solution. The device I was debugging was having
trouble Kermiting files between it and the host. I first used a breakout box to check
hardware handshaking (since the breakout box is specifically for testing the physical
protocol layer, it is of no use for testing the stream or network protocol layer). As it
turned out the handshaking lines behaved correctly. “Now what?”, I thought. I needed
to look at the data coming over the line. My first thought was to use a file capture
program and look at the data stream. I soon abandoned this idea because a file capture
program displays the characters in an ASCII format and since control characters are
used to control data flow, they do not have a corresponding printable character. What I
really needed is a protocol analyzer. However protocol analyzers are expensive, and I
could not justify the cost. So my other alternative is to develop my own. After
weighing the pros and cons I decided it was in my own best interest to develop my own
analyzer. The result of my effort is the Macintosh Break-Out Box (MBOB) protocol
analyzer.
Mac Break Out Box Specification
Supports:
xon, xoff, parity, overrun, framing errors, break detection.
Single filter of operator choosing (editable text dialog).
Clipboard access via resizable window.
Baud rate and parity selection via an editable text dialog.
Menu Layout:
apple symbol | File | Edit | Options
about | Monito | Copy | Baud
| --------- | Clear | Parity
| Quit | Clipboard | Filter
| | | Stop Bits
Listing 1. Specification of MBOB's functionality along with the menu layout.
MBOB is an alternative to expensive logical analyzers. Often, vendors develop
propriety RS232 protocols. Vendors may not have the need or resources to justify the
expense of a protocol analyzer, and MBOB is the tool for filling the void. MBOB
provides basic functionality, in that it filters for a single character which is user
defined, and baud, parity and stop bits are selectable. It uses the modem port of the Mac
and is written in Think C and tested on the Mac Plus through the II lines.
In this article I shall go through the software design process for developing
MBOB. First I’ll generate a design specification, followed by a description of the
functional sections, and then I’ll wrap it up with suggestions on how to improve MBOB.
Figure 2.
Before I begin discussing how MBOB is implemented I would like to talk briefly
about the methodology to produce it. I used a variation of the Yourdon methodology to
produce this application. In a nutshell, the Yourdon design methodology is a formalized
process and notation for developing quality software; quality software is defined as code
which is maintainable, reliable, and thoroughly documented. Normally, this
methodology is broken down into two phases; much like the moon’s only less! First is
the analysis, followed by the design phase.
Usually, the analysis phase starts with a problem definition. During the
analysis stage, designers look for the best solution to the problem. Furthermore, they
also decide if they are focusing correctly on the right problem. In other words,
problem definition starts with an analysis of a proposed solution. If designers discover
that there is a problem with the solution, another is picked and the process is repeated
until they are satisfied with the results of the analysis. Once problem definition is
satisfied, the design phase kicks in.
The Design Phase consists of a statement of purpose, events list, data flow
diagram (DFD), process specification, user interface considerations, and pseudo code.
In the design phase each elements making up the design phase describes the system
from different perspective. For instance, the statement of purpose and the process
specification are often combined to describe in English what problem it satisfies, and
how the system will interact. The event list defines what events the system recognizes
and responds to. The user interface describes what the shell of the system will look
like. DFD’s are used to represents how the system works from a data point of view.
Finally, the designer distills each perspective into pseudo code. Once in pseudo code, the
system is ready for mechanical process of language specific coding.
defaultSettings =
[baudSetting + paritySetting + stopBits + filterChar]
SelectionEvent =
[(menuSelection) + (command key equivalent for menu selection)]